A Virtual Private Network (VPN) uses a public network such as the Internet as a transport foundation to establish secure network communication links. VPN technology uses a public network to provide the appearance of a secure network linking business partners, regional and isolated offices of an enterprise, or other users. A VPN can significantly decrease the cost of providing secure communications among a mobile workforce, or when providing virtual network services which mimic leased-line private access to customers. The effects of VPNs on organizations employing them have been dramatic: sales have been increased; product development has been accelerated; and strategic partnerships have been strengthened in ways never before possible. Since network access is generally available locally, VPNs offer a less expensive alternative to dedicated remote access connections.
The details of VPN implementations are beyond the scope of this disclosure. In general, a VPN is implemented by communicatively coupling a plurality of routers, switches, gateways, and firewalls in one or more local area networks, wide area networks, or internetworks. End stations such as personal computers, workstations, servers, printers, and IP phones are communicatively coupled to the network devices. Although the internetwork infrastructure may be public, the end stations are generally associated with one or more unrelated organizations. To prevent a second organization from receiving and using information transmitted from a first organization, a router at an edge of the first organization's network typically encrypts and specially treats outbound requests. The outbound requests then pass through devices within the network and through any related networks as if they were normal (non-VPN) traffic. Requests can enter a particular destination local area network only if the VPN traffic is associated with that destination network. If not, the request is recognized as outside the VPN and blocked (dropped).
The Simple Network Management Protocol (SNMP) is a well-known application-layer protocol that facilitates exchange of management information between Managed Devices. Using SNMP-transported data referred to as objects (such as packets per second and network error rates), network administrators can more easily manage network performance, configure and provision network devices, find and solve network problems, and plan for network growth. A manager with a Network Management Station will use SNMP, to retrieve or modify information about the status or which is part of the configuration of the network device.
SNMP is defined in multiple versions known as Version 1 (abbreviated herein as “SNMPv1”); Version 2 (“SNMPv2”); Community-based SNMP Version 2 (“SNMPv2c”); and Version 3 (“SNMPv3”). All versions share the same basic structure, components, and architecture. In general, information in an SNMP-enabled device is stored in the form of a plurality of Managed Objects that are arranged in an object tree. Each object has one or more corresponding object instances, each of which has a unique object identifier (“OID”). Values of object instances are stored in tables in device memory; the names of the tables correspond to the names of the Managed Objects. Network Management Stations also keep track of the names of tables and their corresponding OIDs in anticipation of the time when they will issue requests for those OIDs to the SNMP-enabled device.
SNMPv3 defines an extensible framework that supports a new SNMP message format; security for messages; certain forms of access control; and remote configuration of SNMP parameters. In SNMPv3, application entities and protocol entities are called applications and engines, respectively. SNMPv3 also defines a security capability referred to as privacy. The modular nature of SNMPv3 also permits both changes and additions to the security capabilities. SNMPv3 is described in Internet Request for Comments (“RFC”) 2570, RFC 2571, RFC 2572 and RFC 2575.
The SNMPv3 framework also specifies a concept fundamentally similar to a SNMP MIB view called a View-based Access Control Model (VACM). A VACM provides a means for controlling access to information on managed devices.
SNMPv3 also defines a principal; a model-independent principal identifier value that can identify principals for access control purposes (“securityName”); and a model-dependent security ID. A principal is the entity on whose behalf services are provided, or for which processing takes place. A principal may be, for example, an individual acting in a particular role; a set of individuals, each acting in a particular role; an application or a set of applications; and combinations thereof.
A securityName is a human-readable string value that represents a principal. The data format of the securityName is defined as model-independent. In this context, “model independent” means that the format of a securityName is not tied to a specific object model or data model that supports communication security, and can be used with many security data models that interoperate with other SNMP applications.
In contrast, the model-dependent security ID is a model-specific representation of a securityName within a particular security model that is in use at a particular device. Model-dependent security IDs may or may not be human-readable, and have a model-dependent syntax. Examples of model-dependent security IDs include community names and user names. The transformation of model-dependent security IDs into securityNames, and the converse, is carried out by the relevant security model.
All versions of SNMP define a request/response protocol. A network management station (“NMS”) can send multiple requests without receiving a response. Six SNMP operations are defined: Get; GetNext; GetBulk; Set; Notification; and Inform.
An SNMP entity such as an NMS issues a Get request to retrieve a specific Object Instance from an SNMP Agent of a Managed Device. A GetNext request is used to retrieve the next lexically greater Object Instance from a MIB table associated with a Managed Device or its SNMP Agent. A GetBulk request, which first became available in SNMPv2, is used to retrieve large amounts of related information without repeated GetNext requests.
A Set request is issued to set values for specific Object Instances that are managed by an SNMP Agent. The Notification request is used by the SNMP Agent to asynchronously notify the manager of some event. The delivery of this message is not guaranteed; that is, it is unreliably transferred to the manager from the agent. The Notification request is used by the SNMP Agent to asynchronously inform the manager of some event in a reliable fashion. That is, the delivery of an Inform Request to a specific manager is guaranteed.
Given the rise in popularity of both VPNs and SNMP, there is a growing demand for the ability to manage Managed Devices in a VPN environment using SNMP. However, a particular VPN may contain information that should be kept private from users of other VPNs supported on a particular device as well as other non-authorized users that have access to that network. Unfortunately, SNMP does not inherently provide a means to distinguish MIB objects associated with one VPN from MIB objects of another VPN. Consequently, there is presently no workable way to assure user privacy.
Others have proposed approaches to use SNMP to manage VPNs, and still assure user privacy. However, these approaches typically involve explicitly adding VPN identifiers as columnar objects to existing MIB modules. Therefore, these approaches require modification of both standard and proprietary MIB modules, which is undesirable because it may require modification of other existing software, including all existing implementations of MIB modules. Furthermore, modification of standard MIB modules is not possible, simply because they must be implement as-is in order to conform to the standard. Consequently, these prior art approaches are either impossible or are not scalable. In particular, under these approaches, every MIB module that needs to be “VPN aware” has to be modified. In addition, introduction of new tunneling or multiplexing schemes to support different types of VPN operations may require further modification of various objects, further compounding the scalability issue.
Other past approaches have required significant modification to existing SNMP Agent code and/or to existing MIB modules for each new VPN technology supported. These approaches typically required modification of the SNMP Agent's underlying code. This code is present in a particular network device that retrieves or modifies the actual values represented by SNMP objects (the “instrumentation”). This code was modified to add a VPN identifier for use in lookup routines for each VPN multiplexing scheme supported. These modifications involved messy and error-prone changes to the basic Get, Set, and GetNext methods in every affected MIB module. These modifications also sometimes required illegal modification to the standard MIB module text.
The foregoing problems have made such past approaches inconsistent, and resulted in an incoherent access policy for VPN management within system devices. Most companies ultimately employed one or more “hacked” methods for special cases within their systems and there was no consistent company, not to mention industry wide, method for providing management of VPNs.
Based on the foregoing, there is a clear need for a simple and elegant approach to allow the use of SNMP to manage VPNs which provides user privacy, and constrained and secure access to managed devices simultaneously.
In particular, there is a need for a way to ensure that a particular SNMP MIB in part or in its entirety, is accessible only by devices that are participating in a VPN that is associated with that MIB module.
There is also a need for an approach that has minimal or no impact on existing SNMP network management systems. Similarly, there is a need for an approach that has little or no impact on SNMP Agent software development. In particular, there is a need for an approach that requires no modifications to existing MIB modules.